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REMARKS 

Claims 1^99 are pending in the present application. No claims were canceled or added. 
Claims 1, 6^1 1, 17. 1 8, 20, 21, 35, 36, 39-44, 50, 51, 53, 54, 68, 71-76, 82, 83, 85 and 86 
were amended. Reconsideration of the claims is respectftiUy requested. 



I. Ohtection to Claims 

The Examiner has objected to claims 17, 50 and 82 because of the following 
informalities. In claim 17, the phrase "the method of claim 15" should be "the method of 
claim 16." In claim 50, the phrase 'the method of claim 48" should be '*the method of 
claim 49." In claim 82 the phrase 'Ue method of claim 80" sliould be "the method claim 
81." 

By the present Amendment, claims 17, 50 and 82 have been amended to refer to 
the correct claims. Withdrawal of the objection to llie claims is, accordingly, respectfully 
requested. 

IL 35 U.S,C, S 102. Anticipation. Claims 1-1 2> 14-15. 20, 24-25- 31-32, 35. 37-45. 
47-48, S3, 57-58. 64^65. 69-77, 79-80. 85 . 89-90- and 96-97 

The Examiner has rejected claims M2, 14-15, 20, 24-25, 31-32, 35, 37-45, 47- 
48, 53, 57-58, 64-65, 69-77, 79-80, 85, 89-90, and 96-97 under 35 U.S.C. § 102 as being 
anticipated by Appclman (U.S. Patent No. 6,750,881). This rejection is respectfully 
traversed. 

As per independent claim 1, the Office Actions states: 

As per claim 1, Appelman teaches a method in a data processing 
system within a peer-to-peer network m anaging processing of requests, the 
method comprising: 

receiving a request from a requestor; comparing preferences within 
the request to a policy to fomi a comparison, wherein the policy controls 
responses by the data processing system to the requests; and selectively 
responding to the request based on comparison (colunm 6, lines 52-67 
and Figure 11). 

Office Action dated October 4, 2004, page 3. 



Page 14 of 33 
Moskowitz et al. - 09/898,013 



PAGE 16135'RCVDAT 1/4120054:23:32 PM [Eastern Standard T^^^^ 



01/04/2005 15:21 9723857766 YEE & ASSOCIATES PAGE 17 



A prior art reference anticipates the claimed invention under 35 U.S.C § 1 02 only 
if every element of a claimed invention is identically shown in that single reference, 
arranged as they are in the claims. 7« re 910 F.2d 831, 832, 15 U.S.P.Q.2d 1566, 
1567 (Fed. Cir. 1990). The Appelman reference cited by the Examiner does not anticipate 
the present invention as recited in claim 1, because Appelman fails to teach each and every 
element of claim 1 . 

Independ^t claim 1, which is rcptescntative of independent claims 35, 36 and 68 
regarding similarly recited subject matter, recites: 

1 . A method in a data processing system within a peer-to-peer 
network managing processing of requests, the method comprising: 
receiving a request from a user; 

comparing preferences within the request to a policy to form a 
comparison, wherein the poUcy controls responses by the data processing 
system to the requests; and 

selectively responding to the request based on the comparison. 

Appelman does not teach each and every feature of the presently claimed invention in 
claim 1, Specifically, Appehnan does not teach the feamre of "receiving a request from a 
user." The Examiner points to column 6, lines 52-67 and Figure 1 1 as teacliing this 
feature. Figure 11 of Appeknan is reproduced below for the convenience of the Examiner. 
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Column 6, line 52 through coliunn 7, line 2 of Appelman reads as follows: 



FIG- 1 1 is a flowchart showing aii implementation of the 
invention. A User logs in to a Logon System in conventional fashion (Step 
200). The Logon System performs normal logon procedures (e.g., 
requesting a user ID and or a password) and notifies the Buddy List 
System about the User (i.e., passes the User's ED, address, or screen name 
to the Buddy List System) (Step 202). The Buddy List System accesses 
that User's Buddy Lists from a database, which may be, for example, on 
the user's station 12 (Step 204). The entries in the User's Buddy Lists arc 
then compared to the records of the Logon System (Step 206)- This step is 
shown in dotted outline to indicate that the comparison can be done by 
passing records from the Logon System to the Buddy List System, or vice 
versa, or could be done a separate system. The Buddy List System then 
displays a Buddy List window showing the status (i.e., logged in or not) of 
die co-users on the Uscr*s Buddy Lists with any of various indicator 
markings (Step 208). 
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The above cited passage of Appelman does not teaeh the feature "receiving a 
request from a user " Instead, the above cited passage teaches wben a user signs on. he or 
she is automatically ,iotified as to which buddies from their buddy list are currently 
signed on as weU. The user does not make any request. The Logon System, in the course 
of normal logon procedures, not the user, asks for a user ID and/or a password. This 
infonnation is then passed on to the Buddy List System. The Buddy List System then 
fetches the user's buddy list from a database and compares the IDs on the Ust to those 
users currently logged on. This is merely a process wherein the names on the user's 
buddy lists are compared to a list of the currently on-line users and the status of the 
buddy is indicated as either on line or not on-line. Therefore, Appelman. does not teach 
the feature of "receiving a request from a user," as recited in claim 1 of tlie present 
invention. Thus. Appelman does not anticipate the present invention as recited in claim 1, 
because Appelman fails to teach each and every element of claim 1 . 

Additionally, AppeUnan does not teach the feature of "comparing preferences 
within the request to a policy to form a comparison, wherein the policy controls 

responses by the data processing system to the requests." The Examiner points to Column 
6, lines 52 - 67, cited above, as teaching this feature. However, tlie above cited passage 
does not teach this feature. As was discussed above, Appehnau does not teach "receiving 
a request from a user." Therefore, as Appelman does not teach "receiving a request from 
a user," it follows that Appelman does not teach "comparing preferences within the 
request to a policy to form a comparison, wherein the policy controls responses by the 
data processing system to tiie requests." However, even if Appelman did teach "receiving 
a request from a user," which it does not, as indicated above, the above cited passage of 
Appelman still does not teach the feature of "comparing preferences within the request to 
a policy to form a comparison, wherein the policy controls responses by the data 
processing system to the requests." Appelman does not teach or suggest any preferences 
in a request Appelman teaches checking to see if a buddy is logged on or not. There are 
no preferences involved in this activity. Further, no comparison is made against a policy. 
All that is being done is seeing if a user name on a buddy list is currently logged on, 
which does not involve a policy. Therefore Appelman does not teach the feature of 
"comparing preferences within the request to a policy to form a comparison, wherein the 
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policy controls responses by the data processing system to the requests," as recited in 
claim 1 of the present invention. Tlius, Appelman does not anticipate the present 
invention as recited in claim 1, because Appelman fails to teach each and every element of 
claim 1. 

Further, Appelman does not teach the feature of "selectively responding to the 
request based on the comparison." Appcknan doe$ not teach making any selection or 
responding selectively. The above cited passage teaches telling the user if each and every 
buddy on their buddy list is logged on or off. This is not "selectively responding to the 
request," Therefore Appelman does not teach the feature of '^selectively responding to the 
request based on the comparison." Thus, Appelman does not anticipate the present 
invention as recited in claim 1, because Appelman fails to teach each and every element of 
claim 1. 

Tlierefore, for all the reasons st^ed above, Applicants believe that Appelman does 
not teach all the features of independent claims 1, 35, 36 and 68, Accordingly, Applicants 
respectftiUy submit that claims 1 , 35, 36 and 68 arc patentable over tlie Appelman 
reference. 

Claims 2-12, 14, 15, 20, 24, 25, 31 and 32 are dependent claims that depend from 
independent claim 1. Claims 37-45, 47, 48, 53, 57, 58, 64 and 65 arc dependent claims 
that depend from independent claim 36. Claims 69-77, 79, 80, 85, 89, 90, 96 and 97 are 
dependent claims that depend from independent claim 68. As Applicants have already 
demonstrated that independent claims 1, 36 and 68 are patentable over the Appelman 
reference. Applicants submit tliat dependent claims 2-12, 14, 15, 20, 24, 25, 31, 32, 37- 
45, 47, 48. 53, 57, 58, 64, 65, 69-77, 79, 80, 85. 89, 90, 96 and 97 arc also patentable over 
the Appelman reference at least by virtue of depending from an allowable claim. 
Consequently, Applicants respectfully submit that the rejection of claims 2-4, 6^10, 12- 
14, 16, 17, 20, 22 and 23 have been overcome. Additionally, several dependent claims 
recite other additional combinations of features not suggested by the Appelman reference. 

For example, claims 4, 37 and 69 recite the feature of ' Vherein tlie preferences 
provide parameters for which a response is desired.'^ Appelman does not teach or suggest 
this feature. The Examiner points to colunm 3, lines 48-63 and Figure 2b as teaching this 
feature: 
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FIG- 2b is a set of symbolic data records showing the basic types 
of data used by one embodiment of the invention for a Pennissions List 
34, and the conceptual relationship of data elements. Each user in the 
system has an associated Block Status code. If a user's Block Status code 
is equivalent to "none*' , then no co-user may enter that user into the co- 
users buddy lists. Tf a users Block Status code is equivalent to "air\ then 
all co-users ntiay enter that user into their buddy hsts. If a user's Block 
Status code is equivalent to **all except", then all co-users except those 
entered in a linked Exclusion List 36 may enter that user into their buddy 
lists. If a user's Block Status code is equivalent to "none except", then 
only co-users entered in a linked Inclusion List 38 may enter that user into 
the co-user's buddy lists. In one embodiment, a user may only have one of 
an Inclusion List 36 and an Exclusion List 48. 

The above cited paragraph does not teach die feature of 'Vherein the preferences 
provide parameters For which a response is desired/* Instead, the passage teaches about a 
Permissions List, The Permissions List contains a j5eld called Block Status. This field 
stores the type of permission that the user has given regarding other users being able to 
add the user to their buddy lists. The above cited paragraph does not teach anything about 
requests or preferences within requests. The type of information discussed in the above 
cited paragraph is more like a policy. Therefore Appelmaii docs not teach the feature of 
'*wherein the preferences provide parameters for which a response is desired," Thus, 
Appelman does not anticipate the present invention as recited in claims 4, 37 and 69 
because Appelman fails to teach each and every element of claims 4, 37 and 69. 

Similarly claims 5,38 and 70 recite the feature of 'Svherein the preferences 
provide parameters for which a response is not desired," Appelman does not teach or 
suggest this feature. The Examiner points to column 3, lines 48''63 and Figure 2b as 
teaching this feature. As was discussed above regarding claims 4, 37 and 69, the above 
cited passage of Appelman does not teach requests or preferences contained in the 
requests. Therefore, for tlie same reasons, it follows that Appelman does not teach the 
feature of *Svherein the preferences provide parameters for which a response is not 
desired." Thus, Appelman does not anticipate the present invention as recited in claims 5, 
38 and 70, because Appelman fails to teach each and every element of claims 5, 38 and 
70. 



Page 19 of 33 
Moskowitz et al. - 09/898,613 

PA6E21/3S*RCVDAT1/4/20054:23:32PM [Eastern Standard T^^^^ 



01/04/2005 15:21 9723857766 



YEE & ASSOCIATES 



PAGE 22 



Claims 7, 40 and 72 reci tes the feature of "wherein the data processing system 
responds to the request if the policy indicates that the data processing system is 
associated with an employer." Appelman does not teach or suggest this feature. The 
Examiner points to column 3, lines 34-47 and Figure 2a as teaching this feature: 

FIG- 2a is a set of symbolic data records showing the basic tjpcs 
of data used by the Buddy List System 26, and the conceptual relationship 
of data elements. A Group Name table 30 stores user-defined group names 
for buddy lists. Each user may define multiple buddy lists by group names 
(two being shown by way of example). Each group name in the Group 
Name table 30 has an associated Buddy List table 32, comprising multiple 
records. Each Buddy List table 32 record corresponds to a co-user 
("buddy") that the user wishes to track. In the preferred embodiment, the 
record mcjudes data elements for the screen name (or address, such as an 
Internet address) of a particular co-user to be tracked, and the logon status 
of that user (e.g., codes for "In" or "Out"). 

The above cited passage of Appchnan does not teach the feature of '"wherein the 
data processing system responds to the request if the policy indicates that the data 
processing system is associated with an employer." As was discussed above regaiding 
claim 1. Appelman does not teach "receiving a request from a user." Therefore, it follows 
that Appehnan does not teach responding to said request. Therefore, Appehnan does not 
teach the fealure of ' Vhcrdn the data processing system responds to the request if the 
policy indicates that the data processing system is associated with an. employer." Thus. 
Appehnan does not anticipate the present invention as recited in claims 7, 40 and 72, 
because Appelman fails to teach cadi and every element of claims 7, 40 and 72. 

Claims 8, 41 and 73 recite the feature of 'Vherein the preferences identify a group 
associated with the user and wherem the policy allows only interaction with members of 
a same group." Appehnan does not teach or suggest this feature. The Examiner points to 
column 3, lines 34-47 (cited above), column 4. lines 30-47 and 45-54 as well as Figure 2a 
as teaching this feature: 

In the preferred embodiment, when the user first logs into the 
system, the Buddy List window 40 opens, infonning the user which of the 
user 3 buddy list members are currently online. The user can either close 
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this window, or leave it open wbile visiting other areas of Die system. If 
the Buddy List window 40 is left open, the user has a current, real-time 
list of all the user's buddies in who are online at any particular moment. 

FIG- 4 is a graphical display of one implementation of the 
invention, showing a Buddy List Setup window SO with a buddy list 
named "Home List*' in a scrollable area. Buttons are provided for creating 
a new buddy list; editing a selected buddy list; deleting a buddy list; 
viewing the members of a selected buddy list; accessing a Member 
Directory for the system; and accessing a preferences windows. In the 
preferred embodiment, each buddy list is shown in the scrollable area with 
a count of the number of co-users in each list 

The above cited passages do not teach the feature of 'Vherein the preferences 
identify a group associated with the user and wherein the policy allows only interaction 
with members of a same group." Column 3, lines 34-47 of Appelman teaches that a user 
can create multiple buddy lists and give each list, or group, a different name. This 
passage does not teach "wherein the preferences identify a group associated with the user 
and wherein the policy allows only interaction with members of a same group," as it is 
only teaching the creation of multiple groups of buddies and does not teach anything 
about interacting with the groups. Therefore this passage does not teach "wherein the 
preferences identify a group associated with the user and wherein the policy allows only 
interaction with members of a same group," as recited in claims 8^ 41 and 73 of the 
present invention. 

Column 4, lines 30-47 of Appelman teaches that when a user logs on the user sees 
a list of all the user's buddies and whether they are online or not. This passage does not 
teach "wherein the preferences identify a group associated with the user and wherein the 
policy allows only interaction with members of a same group," as it teaches that logon 
infonnation about all the buddies from all the user's different lists will be displayed 
simultaneously. Tliis passage of Appelman does not teach about interacting with groups 
and even if the reference could somehow be constmed as doing so, the reference would 
be teaching interacting with all groups simultaneously, not just one. Therefore this 
passage does not teach *Svherein the preferences identify a group associated with the user 
and wherein the policy allows only interaction with members of a same group," as recited 
in claims 8, 41 and 73 of the present invention. 
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Column 4, lines 45-54 teaches how a buddy list is created and edited. This 
passage docs not teach "wherein the preferences identify a group associated with the user 
and wherein the policy allows only interaction with members of a same group," as it 
teaches thai in order to add a user to your buddy list you must choose a user who is not a 
member of the list, or group, and make him a member. Therefore, the user is not having 
"only interaction with members of a same group." Therefore this passage does not teach 
*Svherein the preferences identify a group associated with the user and wherein the policy 
allows only interaction with members of a same group," as recited in claims 8, 41 and 73 
of the present invention. 

Thus, for all tlie reason stated above, Appelman does not anticipate the present 
invention as recited in claims 8, 41 and 73, because Appelman fails to teach each and 
every element of claims 8, 41 and 73. 

Regarding claim 9, the Office Action states: 

As per claim 9, Appehnan tteches the preferences identify a group 
associated with the requester and wherein the policy allows only 
interaction with members of a different group (column 3, lines 34-63 and 
column 5, lines 23-40; each user can have multiple baddy lists by 
group names, but members of that group can block the user from 
interaction forcing the user to interact with other user in a difTerent 
gt'oup.) 

Office Action dated October 4, 2004, page 4. 

However, column 3, lines 34-63 and column 5, lines 23^40 do not teach "members of that 
group can block the user from interaction forcing the user to interact with other user in a 
different group," as stated by the Examiner. Column 3 lines 34-63 and column 5, lines 
23-40 state: 



FIG. 2a is a set of symbolic data records showing the basic types 
of data used by the Buddy List System 26, and tlie conceptual relationship 
of data elements. A Group Name table 30 stores user-defined group names 
for buddy lists. Each user may define multiple buddy lists by group names 
(two bcmg shown by way of example). Each gn?up name in the Group 
Name table 30 has an associated Buddy List table 32, comprising multiple 
records. Each Buddy List table 32 record corresponds to a co-user 
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("buddy") that the user wishes to track. In the preferred embodiment, the 
record includes data elements for the screen name (or address, such as an 
Internet address) of a particular co-user to be trajcked, and the logon stahis 
of that user (e.g., codes for "In" or "Out"). 

flG. 2b is a set of symbolic data records showing the basic types 
of data used by one embodiment of the invention for a Permissions List 
34, and the conceptual relationship of data elements. Each user in the 
system has an associated Block Status code. If a user's Block Status code 
is equivalent to "none", then no co-user may enter that user into tlie co- 
users buddy lists. If a users Block Status code is equivalent to "all", then 
all co-users may enter that user into their buddy lists. If a user's Block 
Status code is equivalent to "all except'', then all co-users except those 
etltered in a linked Exclusion List 36 may enter that user into tlieir buddy 
lists. If a user's Block Status code is equivalent to '*none except", then 
only co-users entered in a linked Inclusion List 38 may enter that user into 
the co-user's buddy lists. In one embodiment, a user may only have one of 
an Inclusion List 36 and an Exclusion List 48. 

Allow only tlie members below. This option restricts all members 
from adding the user to their buddy lists and from sending the user 
"Buddy Chat Invitations" and other information, except for those co-users 
specifically listed where provided in the window. If set, the appropriate 
user record in the Permissions List table 34 is marked with a code for 
**none except" in the Block Status field, and atj Inclusion List 38 is linked 
to the user for storing the names of included co-users. 

The above cited passages teach that a user may prevent other users from adding 
them to their buddy lists. Therefore, these users would not be on a buddy list. Thus, they 
would not be part of the group. Therefore Appelman does not teach the feature of 
'Svherein the preferences identify a group associated with the user and wherein the policy 
allows only interaction with members of a different group." as recited in claims 9, 42 and 
74 of the present invention. Thus, Appelman does not autieipate the present invention as 
recited in claims 9, 42 and 74, because Appelman fails to teach each and every element of 
claims 9, 42 and 74. 

Further, even if the above cited passage of Appelman could be con$trued as 
teaching that a member of a group could block the user ftom interacting with that 
member, it still does not teach *Vherein the preferences identify a group associated with 
Ihe user and wherein the policy allows only interaction with members of a different 
group." The member blocking his selection as buddy can block or prevent interaction 
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with him by the user. This activity does not prevent the user from interacting with the 
other members of the group. Therefore, Appelman does not teach the feature of ' Vherein 
the preferences identify a group associated witli the user arid wherein the policy allows 
only kiteraction with members of a dijEFerent group/' as recited in claims 9, 42 and 74 of 
the present invention. Thus, Appelman does not anticipate the present invention as recited 
in claims 9, 42 and 74, because Appelman fails to teach each and every element of claims 
9, 42 and 74. 

Claims lOy 43 and 75 recite the feature of "wherein the preferences identify a 
group associated with the user and wherein the policy allows only interaction with 
members of selected groups of members." The Examiner points to column 6, lines 18-43 
as teaching this feature: 



In the preferred embodiment, a user can "minimize" a buddy list to 
suppress display of all the co-users in that group. This is preferably 
implemented so that a double cUck on the buddy list name will cause all 
the screen names listed beneath to disappear. In the prefeiTed embodiment, 
minimized buddy Usts are ixidicated by a symbol next to the buddy list 
name. Double-clicking on die buddy list name again displays all of the 
hidden co-users under that name, A user can also keep tabs on each list by 
checking out tlie numbers posted in parenthesis next to the buddy list 
names. This number tells the user how many people on that list are logged 
in out of the total number of screen names on the buddy list. In the 
illustrated example, 2 3 means that two of the three people on the "Home 
List" are currently online. In tlie preferred embodiment, when the user &st 
logs into the system, the Buddy List window 40 opens^ informing the user 
which of the user's buddy list members are currently online. The user can 
either close tliis window, or leave it open while visiting other areas of the 
system. If the Buddy List window 40 is left open, the user has a current, 
real-time list of all the user's buddies in who axe online at any particular 
moment. 

The illustrated Buddy List window 40 shows a number of buttons 
for setting up or using buddy lists. Included buttons in the preferred 
embodiment are: LOCATE, for determining which **chat room" a buddy is 
in at a particular moment; IM, for sending an "Instant Message"; SETUP, 
for creating and editing buddy lists or setting buddy list preferences; and 
BUDDY CHAT, for inviting buddies to a private chat or a favorite place 
in the system. 
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The above cited passage docs not teach the feature of "wherein the preferences i dentify a 
group associated with the user and wherein the poHcy allows only interaction with 
members of selected groups of members." Instead, it teaches that the user can select 
buddies with whom the user wishes to converse and start chat sessions. Tbereforej it is 
the user who chooses which members of the group to interact with, not a policy. 
Tlierefore, Appelman does not teach the feature of 'Svherein the preferences identify a 
group associated with the user and wherein the policy allows only interaction witli 
members of selected groups of meinbers." as recited in claims 10, 43 and 75 of the 
present invention. Thus, Appelman does not anticipate the present invention as recited in 
claims 10, 43 and 75, because Appelman fails to teach each and every element of claims 
10, 43 and 75. 

Claims 11, 44 and 76 recite the feature of "wherein (he user is a member of a 
group." Appelman does not teach or suggest this feature. The Examiner points to column 
3, lines 34-47, previously cited above, as teaching this feature. However, the above cited 
passage of Appelman does not teach this feature. Instead, the above cited passage of 
Appehnan teaches that buddy lists are grouped and stored under group names. Nowhere 
in this passage, or anywhere, does Appelman teach or suggest that the user is a member 
of this group, the buddy list. Furthermore Appelman actually teaches away from 
*Svherein the user is a member of a group," As the buddy list taught in Appelman is used 
to track whether or not other users are on-line and to request private chats with these 
other users, it would seem unreasonable that the user himself would be on Ms own buddy 
Ust, keeping track of whether he himself was on and requesting private conversations 
with himself. Therefore, Appelman does not teach the feature of "wherein the user is a 
member of a group," as recited in claims 1 1, 44 and 76 of the present invention. Thus, 
Appehnan does not anticipate the present invention as recited in claim 1 1, 44 and 76, 
because Appelman fails to teach each and every element of claims 1 1 , 44 and 76. 

Claims 24, 57 and 89 recite the feature of '^vhea:e^n an existing member of tlie 
group can authorize a new member to the group." Appelman does not teach or suggest 
this feature. Tlie Examiner points to column 5, lines 10-40 as teaching this feature: 
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Allow all members to add me to their lists invitations. 
This option grants permission for all co-usei^ to add the user to their 
buddy lists and send the user '"Buddy Chat Invitations" and other 
infomaation. If set, the appropriate user record in the Permissions List 
table 34 1$ marked with a code for "all" in the Block Status field. 

Block all members from adding me to their Usts invitations. 
This option restricts all co-users from adding the user to their buddy lists 
and from sending the user "Buddy Chat Invitations" and other 
information. If set, the appropriate user record in the Permissions List 
table 34 is marked with a code for "none" in the Block Status field. 

Allow only the members below. 
This option restricts all members from adding the user to their buddy 
lists and from sending the user "Buddy Chat Invitations" and other 
information, except for those co-users specifically listed where provided 
in the window. If set, the appropriate user record in the Permissions List 
table 34 is marked with a code for **none except" in the Block Status 
field, and an Inclusion List 38 is linked to the user for storing the names 
of included co-users. 

Block only the members below. 
This option grants permission for all other members to add the user to 
their buddy lists and send the user "Buddy Chat Invitations" and other 
information, except for those co-users specifically listed where provided 
in the window. If set, the appropriate user record in the Permissions List 
table 34 is marked with a code for "all except" in the Block Status field, 
and an Exclusion List 36 is linked to the user for storing the names of 
excluded co-users* 

The above cited passage does not teach the feature of '*wherein an existing member of the 
group can authorize a new member to the group." Instead the above cited passage teaches 
that the user, and only the user, can add other users to his buddy list Additionally the 
user can choose to prevent other users from adding him to their buddy lists. However, 
nowhere does Appelman teach that a member of a user's buddy list can add other users to 
that buddy hst. Therefore, Appelman does not teach the feature of "wherein an existing 
member of the group, can authorize a new member to the group " as recited in claim s 24, 
57 and 89 of the present invention. Thus, Appelman does not anticipate the present 
invention as recited in claim claims 24, 57 and 89, because Appelman fails to teach each 
and every element of claims 24, 57 and 89. 

Similarly, claims 25, 58 and 90 recite the feature of *Vherein the member of the 
group can initiate a vote to exclude another member of the group." Appelman does not 
teach or suggest this feature. The Examiner points to column 5, lines 10-40 as teaching 
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this feature. As was discussed above in regards to claims 24, 57 and 89, Appclman 
teaches that the user choo$e$ who to imcjude in a buddy list, the members of the buddy 
list have no say in what other users are included within the list. , Therefore, Appeltnan 
does not teach the feature of 'Vherein the member of the group can initiate a vote to 
exclude another member of the group," as recited in claims 25, 58 and 90 of the present 
invention. Thus, Appehnan does not anticipate the present invention as recited in claitns 
25, 58 and 90, because Appelman fails to teach each and every element of claims 25, 58 
and 90. 

Therefore, the rejection of claims 1-12, 14-1 5, 20, 24^25, 31-32, 35, 37-45, 47-48, 
53, 57-58, 64-65, 69-77, 79-80, 85, 89-90, and 96-97 under 35 US.C. § 102 has been 
overcome. 

Furthermore, Appelman does not teach, suggest or give any incentive to make the 
needed changes to reach the presently claimed invention. Accordingly, one of ordinary 
skill in the art would not be led to modify Appelman to reach the present invention when 
the reference is examined as a whole. Absent some teaching, suggestion or incentive to 
modify Appehnan in this manner, the presently claimed invention can be reached only 
through an improper use of hindsight using the Applicants' disclosure as a template to 
make the necessary changes to reach tlie claimed invention. 

Ill- 35 U-S-C S 103. Obviousness, Claims 13. 26-30 46, 59-63, 78. and 91-95 

The Examiner has rejected claims 13, 26-30 46, 59-63, 78, and 91-95 under 35 
U.S.C, § 103 as being unpatentable over Appelman (U.S. Patent No. (6,750,881) in view 
of MacNaughton et al (U.S. Patent No. 6,020,884). This rejection is respectfully 
traversed. 

As per independent claim 13, the Office Action states: 

As per claim 13, Appelman fails to teach a membership in the 
group based on payment. 

However, MacNaughton et al teach a service sign up process that 
requires billing infomiation for the user (column 9, lines 6-26). It would 
have been obvious to one of the ordbiary skiH in the art at the time of the 
applicant's invention to cotnbinc the teachings of Appclman and 
MacNaugJiton because MacNaughton's use of membership fee's in 
Appelman's system would allow for a peer to peer service to charge a 
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usage fee in order to pay for servers and internet connections charges that 
the service occurs. 

Office Action dated October 4, 2004, pages 7-8. 

The Appelman reference does not teach or suggest all the clatto, limitations in 
claims 13, 26-30 46, 59-63, 78, and 91-95, as argued above. 

Furthermore, MacNaughtoti does not cure the deficiencies of Appelman. 
MacNaughton does not teach the features missing from Appehnan, including "comparing 
preferences within the request to a policy to form a comparison, wherein the policy 
controls responses by the data processing system to the requests,^* and "selectively 
responding to the request based on the comparison," nor does the Examiner cite any 
portion of MacNaughton that teaches these features. 

Thus claims 13, 26-30 46, 59-63, 78, and 91-95 are patentable over the cited 
references because the combination of the Appehnan reference with MacNaughton would 
not reach the presently claimed ittvention. The features being relied upon as being taught 
in the Appelman reference are not taught or suggested by that reference, as explained 
above. MacNaughton does not cure the deficiencies of Appehnan. As a result, a 
combination of the references would not reach the invention in claims 13, 26-30 46, 59- 
63, 78, and9K95. 

In view of the above Applicants submit that dependent claims 13, 26-30 46, 59- 
63, 78, and 91-95 are not taught or suggested by Appelman in view of MacNaughton, 
Claims 1 3, 26-30 46, 59-63, 78, and 91-95 are dependent claims depending on 
independent claims 1, 36 and 68. Applicants have already demonstrated that claims 1, 36 
and 68 are in condition for allowance. Applicants respectfully submit that claims 13, 26- 
30 46, 59-63, 78, and 91-95 are also allowable, at least by virtue of their dependency on 
allowable claims. 

Therefore, the rejection of claims 1 3, 26-30 46, 59-63, 78, and 91-95 under 35 
U.S-C, § 103 has been overcome. 
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IV. S 103, Obviousness^ Claims 33. 34. 66-67. and 98-99 

The Examiner has rejected claims 33, 34, 66-67, and 98-99 under 35 U.S.C. § 103 
as being unpatentable over Appelman (U.S. Patent No. (6,750,881) in view of Friedman 
(U.S. Patent No. 6,714,791). This rgection is respectfully traversed. 

As per independent claim 33, the Office Action states: 

As per claim 33, Appelman fails to teach the request is an 
advertisement. 

- However, Friedman teaches the use of advertisements in an instant 
message system (column 3, lines 15-30). It would have been obvious to 
one of the ordinary skill in the art at the tim e of the applicant's invention 
to combine the teachings of Appelman and Freidman because Friedman's 
use of using advertisements in Appelman^s system would allow a peer-to- 
peer service to send advertisements to users based on that user's profile or 
activity- 
Office Action dated October 4, 2004, pages 10-11. 

The Appelman reference does not teach or suggest all the claim limitations in 
claims 33, 34, 66-67, and 98-99, as argued above. 

Furthermore, Friedman does not cure the deficiencies of Appelman. Friedman 
does not teach the features missing fhmi Appelman, including "comparing preferences 
within the request to a policy to form a comparison, wherein the policy controls 
responses by the data processing system to the requests," and ''selectively responding to 
the request based on the comparison," nor does the Examiner cite any portion of 
Friedman that teaches these features. 

Thus claims 33, 34, 66-67, and 98-99 are patentable over the cited references 
because the combination of the Appelman reference with Friedman would not reach the 
presently claimed invention. The features being relied upon as being taught in the 
Appelman reference are not taught or suggested by that reference, as explained above. 
Friedman does not cure the deficiencies of Appelman. As a result, a combination of the 
references would not reaeh the invention in claims 33, 34, 66-67, and 98-99. 

In view of the above Applicants submit that dependent claims 33, 34, 66-67, and 
98-99 are not taught or suggested by Appelm an in view of Friedman. Claims 33, 34, 66- 
67, and 98-99 are dependent claims depending on independent claims 1, 36, and 68, 
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Applicants have already demonstrated that claims 1, 36 and 68 are in condition for 
allowance. Applicants respectfully submit that claims 33, 34, 66-67 and 98-99 are also 
allowable, at least by virtue of their dependency on allowable claims. 

Therefore, the rejection of claims 33, 34, 66-67, and 98-99 under 35 U.S.C. § 103 
has been overcome. 

V- 35 S 103, Obviousness, Claims 21-23, 54-56 and 86-88 

The Examiner has rejected claims 21-23, 54-56 atid 86-88 under 35 U.S-C. § 103 

as being unpatentable over Appchnan (U.S. Patent No. (6,750,881) in view of Nessett et 

al (U.S. Patent No. 6,055,236). 

As per independent claim 21 , the Office Action states: 

As per claim 2 1 , Appelman fails to teach the identity of the 
roquootor user is authenticated using a certificate. 

However, Nessett et al teach authentication is based on a trusted 
third-party called a Certificate Authority (column 25, lines 25-30). It 
would have been obvious to one of the ordinary skill in the art at the time 
of the applicant's invention to combine the teachings of Appelman and 
Nessett because Nessett's use of authentication using a certificate in 
Appeknan's system would alJow a peer-to-peer service to use a third party 
to authenticate a user by proving the user's identity and supplying the 
service with a public key in which to decrypt the user encrypted message. 

Office Action dated October 4, 2004, pages 11-12. 

The Appelman reference does not teach or suggest all the claim limitations in 
claims 21 -23> 54-56 and 86-88, as argued above. 

Furthermore, Nessett does not cure the deficiencies of Appelman. Nessett does 
not teach the features missing from Appelman, including "comparing preferences within 
the request to a policy to fomi a comparison^ wherein the policy controls responses by the 
data processing system to the requests," and "selectively nssponding to the request based 
on the comparison," nor docs the Examiner cite any portion of Nessett that teaches these 
features. 

Thus claims 21-23, 54-56 and 86-88 are patentable over the cited references 
because the combination of the Appelman reference with Nessett would not reach the 
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presently claimed invention. The features being relied upon as being taught in the 
Appelman reference are not taught or suggested by that reference, a$ explained above, 
Nessett docs not cure the deficiencies of Appehnan. As a result, a combination of the 
references would not reach the invention in clairns 21-23, 54-56 and 86-88. 

In view of the above Applicants submit that dependent claims 21-23, 54-56 and 
86-88 are not taught or suggested by Appelman in view of Nessett. Claims 21-23, 54-56 ' 
and 86-88 are dependent claixas depending on independent claims 1 , 36 and 68. 
Applicants have already demonstrated that claims 1, 36 and 68 are in condition for 
allowance. Applicants respectfully submit that claims 21-23, 54-56 and 86-88 are also 
allowable, at least by virtue of their dependency on allowable claims* 

Therefore, the rejection of claims 21-23^ 54-56 and 86-88 under 35 U.S.C. § 103 
has been overcome. 

VI, 35 U.S.C. S 103, Obviousness. Claims 16-19, 49-52, and 81-84 

The Examiner has rejected claims 16-19> 49-52, atid 81-84 under 35 U.S.C § 103 
as being unpatentable over Appelman (U.S. Patent No* (6,750,881) in view of Walker et 
al (U.S. Patent No. 5,862,223). 

A$ per independent claim 1 6, the Office Action states: 

As per claim 16, Appelman fails to teach that members in a group 
exchange compensation for the interaction. 

However, Walker et al teach that users can bid for expert services 
on an electronic auction (column 10, lines 27-43 and column 6» lines 55- 
65). It would have been obvious to one of the ordinary sill in the art at the 
tune of the applicant's invention to combine the teachings of Appelman 
and Walker et al because Walker et al's use of an electronic auction in 
Appelman's system would allow for members of the peer to peer service 
to auction goods and service by using instant messages to communicate 
and exchange compensation for these goods and services. 

Office Action dated October 4, 2004, page 13. 

The Appelman reference does not teach or suggest all the claim limitations in 
claims 16-19, 49-52, and 81-84, as argued above. 
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Furthermore, Walker does not cure the deficiencies of Appelman. Walker does 
not teach the features missing from Appelman, including "comparing preferences within 
the request to a policy to form a comparison, wherein the policy controls responses by the 
data processing system to the requests," and "selectively responding to the request based 
on the comparison,'^ nor does tlie Examiner cite any portion of Walker that teaches these 
features. 

Thus claims 16-19, 49-52, and 81-84 are patentable over the cited references 
because the combination of the Appelman reference with Walker would not reach the 
presently claimed invention. The features being relied upon as being taught in the 
Appelman reference are not taught or suggested by that reference, as explained above. 
Walker does not cure the deficiencies of Appelman. As a result, a combination of the 
references would not reach the invention in claims 16-19, 49-52, and 81-84. 

In view of the above Applicants submit that dependent claims 16-19, 49-52, and 
81 -84 are not taught or suggested by Appelman in view of Walker. Claims 16-19, 49-52, 
and 81 -84 are dependent claims depending on independent claims 1, 36 and 68. 
Applicants have already demonstrated that claims 1^ 36 and 68 are in condition for 
allowance. Applicants respect&lly submit that claims 16-19, 49-52, and 81-84 are also 
allowable, at least by virtue of ttieir dependency on allowable claims. 

Therefore, the rejection of claims 16-19, 49-52, and 81-84 under 35 U.S.C. § 1 03 
has been overcome. 
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Vn. Conclusion 

It is respectfully urged that the subject application is patentable over the cited 
references and is now in condition for allowance. 

The Examiner is invited to call the undersigned at the below-listed telephone 
number if in the opinion of the Examiner such a telephone conference would expedite or 
aid the prosecution and examination of this appUcation. 



DATE: Jj^yft^^y 



Respectfully submitted, 

Gerald H. Glanzoian 
Reg. No.: 25,035 
Yee & Associates, P.C. 
P.O. Box 802333 
Dallas, TX 75380 
(972) 385-8777 
Attorney for Applicants 




GHG/bj 
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